WIP CUDA support #20
WIP CUDA support #20
Conversation
|
Ok I got QR and LQ working. I find the algorithm argument to Has anyone experience with setting up GPU/CUDA test infrastructure? I've created test files with are working locally, but it would of course be good to also have CI for this. |
|
Managed to rebase this locally, will work on getting the tests fixed now |
|
BTW I think also |
lkdvos
left a comment
lkdvos
left a comment
There was a problem hiding this comment.
Looks good to me like this!
I went a bit back and forth between the idea of defining the algorithms in the main package vs defining them in the extension. When we designed the @algdef thing I think we did it in such a way that you don't HAVE to put it in the main package, since it's technically not defining any new structs, simply adding some constants.
The main issue is that this is still a bit annoying to then use as actual qualifiers, so I think this solution is actually better.
I was wondering however if there is a way to make it such that constructing/using these algorithms when CUDA is not loaded would give an error along the lines of "this needs using CUDA".
I'm also okay with just merging this as is though.
| m, n = size(A) | ||
| minmn = min(m, n) | ||
| At = adjoint!(similar(A'), A) | ||
| At = adjoint!(similar(A'), A)::AbstractMatrix |
There was a problem hiding this comment.
Aha, this is where the type assert was added. Is this only JET that complains, or was there really a type instability or type inference issue? I cannot see how asserting an abstract type would help with anything.
Very much work in progress.
A first draft for CUDA support, for now only for QR and untested. My local machine with GPU has currently some issues with installing CUDARuntime.jl, which is a major hinderance for further developing and testing this. I hope this gets resolved soon.
Also, most of the code in yacusolver.jl is either Copilot generated or merely copy pasted and should definitely be ignored at this point.